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Um papfr examines some ^neral rcQuieements for an fnfor tation management 
system for the Deep ^age tletwork (tSNJ lia$S9 wresente a concise review of available 
database management system technologyt Jib recommenas that a federation of 
logically decentralized databases be implemented for the Network Information Manage- 
ment System of the DSN, Overall characteristics of the federation are specked, as well 
as reasons for adopting *his upproach 


I. Introduction 

There have been many advances in database management 
systems over the last decade. Faced with the task of modelling 
a particular application environment, an organization today 
must make important choices. Off>the-shelf products are com- 
mercially available for a wide selection of computers. Nonpro- 
cedural quer>' languages, report-writers, forms-based inter- 
faces, programming languages, and graphics are but some of 
the tools offered for today’s applications. However, before 
selecting a particular product, certain fundamental issues of 
database organization must be considered. Th«^ functional 
requirements of the application environment mvsi be analyzed 
and then carefuUy matched to an information system archi- 
tecture best suited to meet those requirements. 

The purpose of this paper is to study the information man- 
agement needs of the Deep Space Network of NASA, and to 
recommend a database management system architecture which 
will meet those needs most effectively. We begin with an over- 
view of the Deep Space Network, describing the way in 


which the organization is admuiistered, and the ways in which 
various elements of this administration interact with each other 
and with the rest of the Jet Propulsion Laboratory. From this 
discussion we formulate some general requirements for an 
information management system [Section U] . We then turn to 
an examination of information management systems avail- 
able today [Section III] . By matching the characteristics of 
these systems with our requirements, we recommend an 
approach for the DSN, give a top-level design of the system 
using a small, but representative, subset of data, and indicate 
how this system can be expanded to serve adequately the whole 
of the DSN and/or JPL [Section IV) . We then analyze the 
benefits and costs of our choice in comparison witli the bene- 
fits and costs of ar. alternative proposal [Section V] . Lastly, 
we conclude with a brief summaiy of the paper [Section VI] . 

This paper is of paiticular importance because of its timely 
coincidence with plans for the Network infop lation Manage • 
ment System for the DSN already underway. As no major 
software decisions for this system have as yet been made, the 
recommendations contained in this paper may be considered. 
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II. The Deep Space Network 

We begin this section with an overview of DSN operations. 
We then focus in some detail on several key administr tive 
activities. This leads us to formulate general requirements for 
a DSN infonnation management system. 

A. An Overview 

Hie Deep Space Network (DSN) of the National Aero- 
nat^tics and Space Administration (NASA) is responsible for 
the guidance and control of all of NASA’s unmanned space- 
craft at planetary and interplanetary distances, as well as for 
the receiving and processing of the vast amounts ol information 
these spacecraft acquire and send back to Earth. This network 
is made up of tracking stations around the world, a central 
control organization at the Jet Propulsion Laboratory in 
Pasadena, California, and the ground communicatior*' ^inking 
them together. The three station groups, called Deep Space 
Communications Complexes (DSCC), are located approxi- 
mately 120 degrees apart in longitude, so that a spacecraft is 
always in view of at least one antenna as t*..; Earth rotates. 
These locations are Goldstone, California; Madrid, Spain; and 
Canberra, Australia. These stations function as autonomous 
organizations under management at JPL. This management is 
decentralized at JPL in various locations both on and off the 
laboratory, including a secondary site at Hill Street in 
Pasadena. 

A variety of administrative activities in the DSN require 
the management of data. These activities are presently sup- 
ported by separate application systems, each of which has its 
own set of datr^ However, fur many of these activities the data 
overlap. At present, there are few automatic mechanisms for 
these activities to share data. It is cumbersome as well for an 
activity to span several systems. In addition, it is difficult for 
the three Deep Space Stations tc ooperatc in the performance 
of these admmistrative functions or to interchange data 
amongst themselves. 

The need for improving this situation has been recognized 
by JPL management. To this end, an extensive study has been 
undertaken, under outside contract, which has resulted in a 
proposal of a hardware and communications configuration for 
improved operations. The proposed system is called the Net- 
work Information Management (NIM) System. It is for this 
system that we will address our database design. The NIM 
assembly is described in detail in Refs. 1 and 2. The proposed 
worldwide network will initially consist of four nodes, one at 
JPL and one at each of the three station complexes. In addi- 
tion, each node is itself an internal local network. Each NIM 
node will have hardware, software, and communications to 
provide a distributed computing environment for the DSN. 


Hie NIM study, undertaks. t b^ the Aaron-Roes Corporp 
tion for JPL, has produced an extensive survey of aO the 
components of the DSN (Ref. 3). This survey identifies the 
fesponsibilities and requirements of va«iou8 DSN activities 
in terms of their database needs. We shall avail ourselves of 
its contents throu^out this paper in formulating our own 
recommendatiuiis. 

B. Some Important Administrative Activities 

In this discussion we will focus on some important adminis- 
trative activities of the Deep Space Network in order to 
determine a design for an information management system 
which will permit these activities to function efficiently, and 
which will give management tlie overview and knowledge it 
needs to do its job well. Because the totality of these activities 
is much too great for the sc^pe of this report, we will ca cen- 
trate on several important operations which span the entire 
organization. 

1. Engineering Chan^ Management (ECM). En^eering 
Change Management is a complex, far-«^aching DSN acti,ity. 
It is coordinated at present by a group in section 377 at JPL, 
directed by a Change Control Board, and involves a large 
number of personnel throughout the JPL/DSN organization. 
The process of instituting an engineering change involves the 
initiation of an Engineering Change Request (ECK). This 
request is carefully assessed by representatives from all other 
systems that might be affected by the change. The assessments 
then brought before the Change Control Board, which 
passes judgement on the request. The request may either be 
denied, approved, or sent back for further evaluation. Once a 
request is approved, one or more Engineering Change Orders 
(ECOs) are issued to design and implement the change. Each 
ECO is then planned in ietail, with costs and scheduler devel- 
oped for each phase. At uiis point the evaluation phase is 
complete and tlie design and implementation phase begins. 

During the design and impierien ration phase the ECM 
group functions to collect status information about the actual 
sched e performance, and to alert management if a.iy resched- 
uling will be required. A general awareness of the progress of 
the ECO is needed by everyone involved, including logistics, 
maintenance, and mission planning personnel who need to 
know when the installation will actually occur. As the Aaron- 
Ross survey points out . . an ECR has the potential to affect 
nearly every aspect of DSN operations and support, ranging 
from mission performance analysis to spare parts provisioning 
and from maintenance personnel scheduling to DSN utilization 
forecasts. As a consequence, there is a large constituency of 
personnel, witli widely varying needs, all of whom absolutely 
requiie or can benefit by a conveniently obtained status and 
schedule foi.cast for ECOs. 
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Whoi the design and implementatioa of the ECO are com- 
plete, the instaDation at the tmddng sites begins. The schedul- 
ing of the installation the equipment must be coordinated 
with the tracking schedules, so as not to interfere with any 
mission, and yet be there in time for any future mtssicms 
that require it. There are also, in additicn, scune temporary 
ECOs whose removal must be scheduled siiiiilarly. When the 
equipment is finally installed and running, or when the tem- 
porary equi^anent is remov^^d, die ECO is closed out. 

The Engiimring Change Managenmntis cleariy an important 
activity, having the c^iabifity to affect the DSN in many ways. 
The data representing the ini^timi and assessment phases 
are of inters to a variety of people at JPL, while the data 
for tl^ development, implen^tation, and instrOation sched- 
ules may be needed by a variety of personnel thToug^out the 
entire organization. 

2. Equipment and Materials Managemmt. This DSN 
activity is responsible for the management of JPL property, 
DSN tracking equipment, repairable q>are parts, other mainte- 
nance spares, and consumables. Management of equipment 
and materials involves obtaining them in the first place (pro- 
visioning and procurement), keeping track of their location 
and status (inventory and control), and moving them from 
{dace to place (tranqiortation and shipping). These activities 
are distributea among several organizational elements at JPL 
and at the Deep Space Stations. 

3. Anomaly Reporting Services. The knowledge and con- 
trol of anomalies occurring from time to time throughout the 
DSN is an important activity for its well being. To this end the 
DSN has procedures for the reporting of various anomalies. 
Two categories of reports which ^tre processed are Discrepancy 
Reports and Failure Reports. The ultimate goal of these 
reports is to provide DSN engineering, operations, support, 
uid management information on which to make changes in 
equipment, technology, procedures, and policy. There are 
three basic activities connected with these reports. These are 
(1) filling them out, (2) validating, investigating, and analyzing 
them, and (3) summarizing the status of the anomalies to 
management. 

4. Other DSN activlti^ In addition to the three activi* 
highlighted above there are many more too nunterous t': i' 
These include lergy management, finanaal mana^' ^it, 
personnel management, scheduling, maintenance, production 
control, as well as activities that pertain to the tracking sites 
only, such as operations, repairs, maintenance and integration, 
cabling, etc. For each of these activities the efficient manage- 
ment of data is extremely important. 


C. QenerilfleqiibwneiMItoraDSNIiil^^ 
Management Sy^em 

There are three general requirements for an informatsoa 
management syston for the DSH. Fust of all, the ^stem must 
permit tte necessary interdiange of data between the vmom 
adminstrative activities, as wdl as between die various physica* 
sites of the organizatiem. Secondly, the system must dlow 
eadi of these activities to develop and function autonomous^. 
And, diirdly, the system must be c^iable of ewdving mere- 
mentally over time. 

1. Tile need for diariiig. There are some obvious rebtioi- 
diips between the various DSN tuaaagBmmt activities. For 
examfde, there is a natural interaction between d» ECU sys- 
tem, the equipmrat mmagement ^stem, and the wuunaiy 
reporting system. An ECO almost always wfll affect the 
equipment database. Eitiier new equqnnaat wfll be imaOsd 
or dd equipment will be removed, or both. Anomaly reports 
can and often do result in the initiation of an ECR. Further- 
more, the irnd^^tatimi of an ECO can r^t in anomalies. 
And so on. At present none of these interactions can take 
place automatically. Relationsh^ are maintained manually, 
if at an. 

In addition to the need for having activities share informa- 
tion, JPL management needs to have an overview of DSN 
operations. This overview requires the integration of data from 
separate sources within the DSN. JPL might need to know, for 
example, which stations have com{deted installation of ECOs 
for a given ECR, or it might need to compare the cost of the 
installation from one site to another. The ability to discover 
unknown relationships is also desirable. There is currently no 
easy way for management to determine if, for example, a 
particular piece of equipment causes the same problems at 
each site where it is used, or for two sites with the same prob- 
lem to benefit from each other's experience. 

To overcome, in part, this problem of management's diffi- 
culty in deriving composite information from various sources 
within the DSN, a pilot system is currently being developed at 
JP!. which will provide integrated data concerning DSN opera- 
tion>, maintenance, and repairs at Goldstone (Ref. S). This 
system, called the Productivity Information Management 
System (PIMS), will provide its users, both managers and 
management scientists JPL, a set of tools for manipulating 
data in a variety of way. Management scientists will then have 
the capability to develop and verify operations research 
models. The implementation of efficient operational policies 
can then lead to substantial savings and cost reductions. 
Because the data that management needs is decentralized, and 
stored in different forms, using different overall methodol- 
ogies, a major integration effort such as PIMS is presently the 
only way to provide the overvf. w so badly needed. 


146 



2. Tbe aeed for autosomy. In addition to the need for 
sharing infonnatkm, there is a ccMiOkrtiiig need for activities to 
remain autemomous. The various DSN management activities 
are separate and distinct apjdications. They have developed, 
and continue to develop, independently of each other, and are 
under autonomous local cmitrol. Int^rating the data from 
all of these activities into a sin^e centralized datab^ is 
restrictive. Local control of the data is an importuit aspect of 
the DSN, as is the independence of one activity from another. 
It is, therefore, neither desirable nor practkal to develop a 
spedfication of the totality of operational data for the DSN 
and to design a logically centralized iatabase. 

3. The need for evolvalnlity. Cou|ded with the need for 
autoncmiy is the need for evolvability. Administrative activities 
evolve with the growth of the organization. Some functhms 
are replaced, others are added. The information management 
of these activi ies must be capable of evolving also. The data- 
base must at aU times be an accurate reflection of the organiza- 
tion. It must therefore be dynamic, capable of changing and 
growing as the DSN changes and grows. 

Evolvability of the information management ^tem is 
important for financial reasons also. Funding comes not all at 
once, but in small increments over time. The information man- 
agement system must be capable of incremental development. 

Hi. Database Management Systems 

In this section wc consider available choices for database 
management systems in the 1980s. We begin with a brief 
discussion of data models. We then present a historical devel- 
opment and description of Oatabise management system 
architectures. 

A. Data Models 

A data model is an abstract representation of the informa- 
tion content of the database. As such, its main function is to 
insulate the user from the implementation details of the data- 
base. Typically, the data in the database is represented using a 
''conceptual*' schema, which is an instance of a given data 
model. (The relationship of database schema to data model is 
analogous to that of a pn^ram to a programming language.) 
The data model provides both data structures for representing 
data and operations for manipulating them. The three best 
known data models are the hierarchical model, the network 
model, and the relational model. We now give a brief descrip- 
tion of each of these, and site some of the more well-known 
implementations of each. 

I. Hierarchical data model. In the hierarchical data model, 
the data are represented using trees and links. One designated 


record type occupies the top node of the tree, whfls its depaw 
dent record types are at nodes on lower fevMs of the tiee. The 
links connect occurrences of these records. These stmetwes 
model one^o-many lektioiidiips, sacs every dependent 
record can have at most one parent record. As an flhstratiaa 
of the use of this model, let us consider the canonical example 
of sui^diers «ul parts. To represent the rehtfonsfaip of snp- 
phers to parts suppfod we would have a forest of trees, witha 
particular supfdier at the top of each tree, mi the parts sup- 
plied by that supplier at the nodes on the mxt leveL 

Some of the longest established database management sys- 
tems adopt the hierarchical approach to data orgnizatkn. 
These indude tte Infovmatton Management System (IIB) of 
IBM, System 2000 of MRl, and Mark IV of Informatics. 

2. Network data modeL Many of the relattondiips inherent 
in a database are not <me-to-mmiy, but many-to4iuny. To 
capture these kinds of relatkaidups a m<»e general structure, 
called a network, was introduced. A network can be viewed 
as a graph containing no<tes and bidirectional finks. Ahhougli 
this allows more flexibility tha ' the hierarchical model aid is 
more efficient in some cases, it is considered more complex. 

The most important example of netwoik systems is pro- 
vided by the proposals of the CODASYL Data Base Task 
Group, DBTG. Two commercial systems based on these pro- 
posals are MIS 1100 by Univac, and IDMS by Culfinmie. 
Other network systems indude TOTAL by Gneom, an * IDS 
by Honeywell. 

3. Rdatioiial data model. In the relatkMial model data are 
organized into tables, called relations, which dosely corres- 
pond to traditional files. The rows of a table correspond to the 
records of a file, and the cohimns correspond to the twins of a 
record. Associations between the rows are represented solely 
by data values in columns drawn from a common domain, or 
pool of values. All of the information in the database, entities 
as well as relationships, h represented in a single uniform 
manner, namely Li the form of tables. This uniformity of data 
representation results in a corresponding uniformity and 
simplidty in data operations. 

In contrast to the hierarchical and network models there 
are no interrecord links in the relaticnaJ model. This feature 
gives the relational model an independence from the under- 
lying phycical realization of the database. The physical depen- 
dence of the hierarchical and network systems stems from the 
encouraged association between the physical access paths and 
the logical intenecord links. The absence of such links gives 
the relational model an added degree of flexibility. 


147 



Relational systems aie histoiicatty tlie most recent. Some of 
the better4mown rehtiooal systems are SQL/DS (System R) 
ami Queiy-By-Example from IBM, INGRES from Reiatiooal 
Techiioiog>\ NOMAD from Natioiial CSS> ORACLE from 
Relational Software, and ENCOMPASS from Tandem. 

4. Semantic data aaodek. In addition to the three conuner- 
dally avaiUMe data tnodds described above, there have recently 
been developed some higher4evel models winch allow the 
meaning, or semantics, of the database to be incorporated 
more completely into the schema. These models differ from 
the record<oriented models above by employing constructs 
that are more user oiiemed. such as objects, types of objects, 
aid attributes of objects. 

There are many semantic modeb currently in use, but their 
usage is mainly academic. That is, there are no direct imple< 
menutions of any of them as products. Some of the more 
well-known of these modeb are the Entity-Reiationship Model 
(Chen 1976), the Semantic Database Model SDM (Hammer 
and McLeod 1978), the Extended Relational Model RM/T 
(Codd 1979), and the Event Database Model (King and McLeod 
1981). 

B, DBMS ArcMtaclitfes 

It b useful to dassify databa^ according to whether they 
are logically and fdiysically centralized or decentralized. Using 
thb framework, four classes of data base architectures can be 
identified. Logically centralized and pliysically centralized 
databases include conventional integrated databases. Logi- 
cally centralized and physically decentralized databases 
include ^^distributed datat>3se$*\ as ws.ll as a number of recent 
approaches to composite database support. Logically decen- 
tralized and physically centralized or decentralized databases 
are the domain of federated databases. 

I. Logk^y centralized, physksOy centralized systems. 
Nearly all database management systems in use today, includ- 
ing all of those mentioned in Section Ill-A. manage databases 
that are both logically and ph>sically centralized. This means 
that a single conceptual schema, derived from a formal data 
model such as the ones mentioned above, is used to structure 
all of the da^a v the database. It also means that alt of ihc 
data in the dat c are stored in one location. There are three 
main reasons for integrating data thusly. from separate sources 
and varying applications, into a unified, coherent whole. One 
reason is that duplication of tlic data from one source to 
another is greatly reduced. The second is that the data becomes 
logically and physically independent of the application pro- 
grams that use it. This means that the physical details of data 
stoiage and access methods are handled b> the system. The 


entire GoOectk» of data fan the oigaaiiation b now an hnpor- 
taat raoiiroe, easy to aooesa and use foz a nriaty of #paise 
ypikations. The third reaaon is that dw data ara now under 
oootiol of a oentrafod authodty, who makes dadsions for 
the good of the oiganteatfon as a whole rather than any one 
application. 

2. Laglcaly oentiaHned, physicrily d e cjr.ntiaii a B d ^f stwm 
The advantages of integrated databases were widely lecogpiiaed. 
However, in some ai^dkatioas^ the organization itself is geo- 
graphically distnlmted. Havii^ the data stored in one oantrri 
location means high communications costs and dagradad sys- 
tem performance. Therefore, the next step taken In DBMS 
research was to take the data in a logicMIy oentiaiiied data- 
base and physicaily dtstribute it among the various nodes of a 
computer network. Thb physical dbtiBiiition b tocdOy tzans- 
parent to the user of the ^rstem. That b, to the user of the 
database it b as if aB of the data were in one place. The svs- 
tero's performmoe b impfoved because the data b Mc&ted 
where it b accessed most frequently. Dbtifoution of the 
uatabase to optimize paraSel processing beemnes a key iesiffk 
issue for distributed systems. Another key feature of distri- 
buted systems b the possibility of incieased reUMulity. A 
company can reduce the disaster of a computer failure by 
duplicating the data at more than one rite. These features of 
dbtributed systems make them highly desirable for many of 
todays application environments. Therefore, much research 
and development on dbtributed systems b currently taking 
place. Added complexities involving consbtoicy of redundant 
data, recovery from a failure at any rite, and control of con- 
current processing pose some difficult research problems. 
Rr<^!otypes have, however, been built, most notably SDD-I 
by Computer Corporation of America. It should not be long 
before a dbtributed DBMS will be commercially available. 

3. Logkaily decentralized systems. Both conventional 
and dbtributed systems, though they differ in their physical 
realization, are logically the same. A single conceptual schema 
defines all of the data in the database, and the control of the 
database b centralized, even though the data may not be. Thb 
can pose, and has posed, some problems, it has been, in some 
environments, very difficult to integrate data from many 
applications because the views they have of the data are 
different. Logical centralization can force the coupling of 
data where the retention oi some individual autonomy is 
desirable. Each user of a centralized system b forced to 
surrender the control of the structure of his data to a central 
authority, who has the task of organizing all of the parts 
into a coherent whole. This can have drawbacks. Many individ- 
uals are very reluctant to relinquish control of their data, so 
much so that many an attempted database effort has failed 
for this reason. Even where this is not the case, centralized 
control often creates a large bottleneck through which all 


148 



requests foi dungte must |>ass. Changes, therefore, occur 
rehictanUy md slowly, resulting in inaccuracies and anach- 
ronisim in the database. In addition, the inb of the central 
authority is an enormous one. for this pcrsim (or persons) 
must understand every aspect of the organization thoroughly 
m order to model the data well, and must also have a thorough 
knowledge of DBMS software. The database administratoifs) 
must choose a design tor the system which optimizes usage 
for the whole collection of users, a design which, however, 
is often much less than optimal for any one user. Thus, the 
benefits of integration can have a very high cost. 

The notion of a federated database architecture was intro- 
duced to remedy these probkins. A federation is a union of 
two or more logically decentralized sources of data which may 
be. but need not be. physically decentralized. The essential 
difference from the systems above is the logical decentraliza- 
tion. The individual components of a federation remain under 
auionomous local control with, however, a certain amount of 
sharing and coordination. One component of the federation is 
distmguishcd as the federal controller. It keeps track of the 
topology of the federation, and aids in the entrance or depar- 
ture of a component into or from the federation. The compo- 
nents themselves, through the communications facilities pro- 
vided by the federatkm. define the system and negi>tiate their 
interactions. Each component has its own schema, which 
states ^icK of its data is private and which i$ to be sliarcd in 
the federation. Individual members of the federation may 
change tntenially so long as theu interface to the fedetation is 
maintained. The federated architecture is both dynamic and 
modular, with components coming and going at any time. It 
therefore cames with it all of tlie well-known benefits of 
dynamic modular systems. 

The research on federated .systems is relalivdy new. and to 
dale there is only a small working prototype at the l^niversity 
of Southern California. However, as a compromise between 
total integration on the one hand and total autonomy on the 
Ollier, it IS highly desirable Um many of today's applicatums. 
In addition, the trend today away from large mainlrame 
computers toward networks of smaller machmes makes the 
federated approach to database organization particularly 
appropriate 


IV. A Database Management System 
for the DSN 

In this section we bring together the requirciiKnts of 
Section 11 and the system characteristics of Section III to 
recommend a system tor the DSN. We then describe in Si>me 
detail the nature of this system. 


A. A F^darrtBd System tor ttie DSN 

In choosing an archilectuit for the DSN we must satofy 
the thiee previously slated requiraments. These aie (I) applica- 
tions must be able to shaie data and actmtle8;(2) appUatkms 
must retain individual autonomy and control of their data; and 
(3) applications must be abks to change with time. 

Logically centralized ^tenis fail to meet the second 
requirement. If we weie to adopt a centralized database 
architecture for the DSN. all of the data from aD of the 
apphcaiions would have to be under centralized control. As we 
have seen from the examples in Section II. this is impractical. 


Logically centralized systems also do not meet our third 
requirement very well. Because at any one time the totality of 
the database must be represented in a single logical schema, 
changes in the database require a redesign of the schema. 


The characteristics of federated databases, on the other 
liand. seem to be perfectly matched to the needs of our DSN 
environment. Federations allow for local autonomy, while 
facilitating the sharing of data and activities. Federations are 
also capable of evolving over time. Let us take a closer look at 
what a federated information matiagen.ent system for the DSN 
would be like. 


I. The iapaiogy of Che fedetation. The components of a 
federation are die logically autonomous units of an organiza- 
tion that sometimes need diare data or jointly to pcrt'orin 
Si)ine action. In the case « ? DSN. these components are 

the various administrative .les described earlier, such as 
Engineering Change Manageu..^tit. Equipment and Materials 
Management. Anomaly Reporting. Repairs. Cabling, etc. A 
distinguished component, whicli can be distributed among the 
sites or be resident at JPL is the federal dicuonary. whose 
task It IS to record the topology of the federation. The diction- 
ary acts in cstablislung. maintaining, and terminating the 
federation, as well as in monitoring structural changes. 

ILach application that needs autonomy, whether it be 
ECM or Repairs or anything else, will be a logical component. 
Some of these conrponents will reside on the same machine, 
others may reside at other NIM nodes, while still others may 
be distnbuted througiiout the NIM computer network. The 
degree and nature of sliaiing and ci>operation among these 
'unents will be expressed in the component schemas. 
The federation provides an integrated set of intercomponent 
communication facilities. These are data importation for data 
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shaiing, message passing for transactkm sharing, and negotia- 
tion for cooperative activity. 

2. Hie oompooeiit sdiemaa. Each component of a federa- 
tion is a logical entity having its own compmient schema. 
This schema describes tlw mformatum of cnooem to the 
oomponent a^id has three parts: an export schema, which 
specifies the infoimatioo it is wdhng to share with other 
components; an import schema, which specifies the infor- 
mation in the federation that the cmnponent wishes to access; 
and a private sctona, which specifies local informatioo, which 
the component is unwilling to share at afl. 

The export schema for the ECM ctunpcment would likely 
contain roost of its data, since ECM is a network-wide activity. 
Its import schema would contain the items exported from the 
equipment database, cablmg database, anomalies database, and 
possibly others. Other compcments, such as Repairs, would 
have a larger i»ivate schema while exporting relatively less 
information. The actual content of these schemas wiU be 
decided throu^ the negotiattcm mechanisms of the federation 
according to the needs of the components. 

It is highly possible that one component importing data 
from another wiU need to have a different view of the data. 
The federated model also provides operators for deriviiig both 
types and attributes. This means that is is not necessary for 
compmients to agree on a common view of the data for shar- 
ing to take place. 

The federal dictionary component is the repository of 
information global to aU components, which includes infor- 
mation describing the structure of the fedenitkm. Its import 
schema is used to collect this global information, while its 
export schema is used to share it with the other components. 
Any component of the federation can find out from the 
dictionary what components currently constitute the federa- 
tion, and how it may communicate with them, as well as 
obtain a summary of the kinds of information available. 

3. The data model. The federated architecture requires a 
common data model to be used throughout the federation, 
although a component may use any data model of its choice 
for internal use. Each component uses the federation model 
to define its export, import, and private schemas. The federal 
dictionary component uses the model to define the structure 
of the federation. 

While it is poss e that any data model could be made to 
work as the federation model, a semantic model, such as the 
Event Database Model (Ref. 4) is preferable because many 
kinds of relationships between the data can be represented. In 


addition, sanoe the model is not tied to my particular idiysteal 
lepresentatioo, the underiysig physical inqdeniefitaticm ot the 
database can change withcmi . 'ectmg its k^lcal exptessim. 

If the log^ components of the federatkai use a different 
model than the federation mortel, a translatioii can be made 
between the two. This is impwtant if components are to be 
managed with DMIS software commercnBy availahte to<faiy« 
Because of the simplicity and structural mdependoioe of the 
lelatimial model, it is the best commercial du^ availaUe 
today for the components to use. 

B. Evolving tlieFMertfion 

One of the advantages of ad<H>ting the federated a|^»oacfa 
to database organization is that the database can be developed 
incrementally. Components can come sito m depart from 
the federation at any time. A cmnponent cm also c hang e 
internaOy, so long as it supports its interfeoe to the federa- 
tion. This evohrabOity is particulariy aporc^mate for the DSN, 
as funding is easier to obtain in increments. The federatkm can 
grow both within the NIM system and beyond. 

1. Within the NIM. The extendibility of the federated 
architecture means that as the NIM cmrununications and 
hardware expands, so does the federated informaticm manage* 
n^t ^stem. The federation for NIM can evolve from the 
components themselves. They will each express their own 
export, import, and private schemas, and will use the negotia- 
tion mechanism of the model to achieve a desirable configura- 
tion. This configuration need by no means be statk. Compo- 
nents can negotiate for their entrance or removal from the 
federation, as well as lestructure themselves internally. This 
means that as new applications are added to the NIM system 
they can easily become a part of the federation, and assures 
that the federation will always be an accurate model of the 
apf^kation environment. The basic ones of auton<miy and the 
patterns of interaction are the governing design principles to 
be embodied. 

2. Beymid the NIM. The federated architecture can also be 
extended to include components outside the NIM assembly. 
This is particularly desirable, for the OSN needs to interact 
with various JPL institutional systems from time to time. 
These include institutional systems for financial management, 
personnel management, property management, work sched- 
uling, mission planning, etc. A higher-lcvet federation, one 
with the NIM federation as one component (the OSN compo- 
nent) along with these other in«‘titutional systems, can be 
envisoned. The principles of design are the same. All u&at is 
needed is the necessary hardware and communications to 
link them together. 
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V. Cofi^MWisim of an AttemaAive Choice 

In this Huai section we consider a proposed alternative to a 
federated system. In our evaluation, we focus on two basic 
features. The first of these is the desirability of a general- 
purpose vs a special-purpose system. The seauid is the desir- 
ability of a dynamic vs a static system. .Mso, the life-cycle 
costs of both choices must be conddered. 

The database system now under consideration for the DSN 
is a system of separate, uutependent databases for each af^li- 
caticni on the NIM. This approacii is an electronic counterpart 
of the situation that exists now, and can be adiieved with little 
research or developmaitt effort. As before, each application 
will own its data. However, because of the communications 
provided by the NIM network, any apfdication wiD be able to 
peruse the frtnn any other application's database. Never- 
theless, one apidkation will not be able to use the data in 
another database without writing a program to incorporate 
that data into its own system. The imported dat*^ will iiave to 
be duplicated, interpreted, and restructured before it can be 
used. Composite informatiem will still be extremely ditlicult to 
obtain. This is because each application will have data in 
different and incommensurate forms. Hie task of utilizing 
these different views of the data is not trivial, and standardiz- 
ing these views is tantamount to centralization. In addition, 
keeping redundant copies of data creates a problem of consis- 
tency with updates that must be dealt with. The costs of 
dufdicate storage space, and of time to transmit copies back 
and forth across the network must also be considered. 

While it is true that the interactions provided by the fed- 
erated model can be realized on a case-by-case basis by means 
of ad hoc application programs, this can become extremely 
costly in the long run. For, as the number of components 
increases, the cost of application software to tie them together 
grows geometrically, whereas the cost of the federated soft- 
ware stays the same. The federation provides a general-purpose 
system for maintaining autonomy while facilitating sharing. 


The distinction between the ad hoc alternative approach and 
the federated approadi Is the distinctkio between graeraiity 
and flexibility on the one hand, and specificity and rigMUty 
on the other. 

Also, if it were possible to state at any one time aO the 
ways in which the data are to be diaied unongst the users oi 
the NIM then one could implement the necessary programs to 
do this. However, obtaining such a spedficatioa is unrealistic. 
Changes are a fact of life, and the ability to respond to dianges 
is ** highly desiiable feature, saving mudi cost over the years. 
Only a federated system offers the ability to change these 
interappUcation, intercomponent relationddps dynamically. 
Therefore, it is the life<ycle cost of each ahemative that 
must be compared. The added time, effort, aid dollars neces- 
sary to impiement the federated informattmi managanent 
system, from first principles, is more than hkety to pay for 
itself as time goes by. 


VI. Conclusion 

In this paper we have examined several key DSN adminis- 
trative functions. We have seen how these activities need to 
have a data management system whndi wiii allow them to 
retain their individual autmiomy and which will also aDow 
them to share data. We have also seen that these activities 
need to be able to grow and change independently of each 
other. They therefore require a data management system 
that is dynamic. 

We feel that the federated approach to database organiza- 
tion IS particularly appropriate to this atuation. We also feel 
that the benefits of implementing it far outweigh the costs. 
The development of a federated information management 
system is an ambitious undertaking, but one worthy of such 
an important organization as the DSN. The results are very 
exciting to contemplate. 
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